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We present a parametric calculus for contract-based computing in distributed systems. By abstract- 
ing from the actual contract language, our calculus generalises both the contracts-as-processes and 
contracts-as-formulae paradigms. The calculus features primitives for advertising contracts, for 
reaching agreements, and for querying the fulfilment of contracts. Coordination among principals 
happens via multi-party sessions, which are created once agreements are reached. We present two 
instances of our calculus, by modelling contracts as (i) processes in a variant of CCS, and (ii) as 
formulae in a logic. With the help of a few examples, we discuss the primitives of our calculus, as 
well as some possible variants. 

1 Introduction 

What are contracts for distributed services? How should they be used? These questions are intriguing 
not only researchers but also practitioners and vendors. In fact, contracts are paramount for correctly 
designing, implementing, and composing distributed software services. In such settings, contracts are 
used at different levels of abstraction, and with different purposes. Contracts are used to model the 
possible interaction patterns of services, with the typical goal of composing those services only which 
guarantee deadlock-free interactions. At a different level of abstraction, contracts are used to model 
Service Level Agreements (SLAs), specifying what has to be expected from a service, and what from the 
client. Also in this case, a typical goal is that of matching clients and services, so that they agree on the 
respective rights and obligations. 

Contracts have been investigated from a variety of perspectives and using a variety of different for- 
malisms and analysis techniques, ranging from c-semirings (7l[8][T5l, to behavioural types @QJJ[TT|], to 
formulae in suitable logics H][3]|2T]], to categories [9], etc. This heterogeneous ecosystem of formalisms 
makes it difficult to understand the essence of those methods, and how they are related. 

As a first step towards remedying this situation, we propose a generic calculus for Contract-Oriented 
COmputing (in short, CO2). By abstracting away from the actual contract language, our calculus can en- 
compass a variety of different contract paradigms. We provide a common set of primitives for computing 
with contracts: they allow for advertising and querying contracts, for reaching agreements, and for ful- 
filling them with the needed actions. All these primitives are independent from the chosen language of 
contracts, and they only pivot on some general requirements fixed in the contract model proposed here. 

A remarkable feature of our approach is that contracts are not supposed to be always respected after 
they have been stipulated. Indeed, we can model the quite realistic situation where promises may be 
possibly reneged. Therefore, in CO2 contracts are not discharged after they have been used to couple 
services and put them in a session, as usually done e.g. in the approaches dealing with behavioural types. 
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In our approach, contracts are also used to drive computations after sessions have been established, e.g. 
to detect violations and to provide the agreed compensations. 

Synopsis. The overall contribution of the paper is a calculus for computing with contracts in distributed 
systems. The calculus is designed around two main principles. 

The first is the separation of concerns between the way contracts are modelled and the way they are 
used in distributed computations. Indeed, we abstract from the actual contract language by only impos- 
ing a few general requirements. In this way, we envisage our calculus as a generic framework which can 
be tuned by instantiating the contract model to concrete formalisations of contracts. In §[2] we present the 
abstract contract model, followed by two concretisations: in § 12. 11 we adopt the contracts-as-processes 
paradigm whereby CCS -like processes represent contracts that drive the behaviour of distributed partici- 
pants; in § |2.2| we embrace instead the contracts-as-formulae paradigm, by instantiating our calculus with 
contracts expressed in a suitable logic. We relate the two concrete models in § 12.31 first with the help of 
a few examples, and then by showing that contracts-as-formulae, expressed in a significant fragment of 
our logic, can be suitably encoded into contracts-as-processes (Theorem I2.7I ). 

The second design principle of our calculus is that its primitives must be reasonably implementable in 
a distributed setting. To this purpose, we blend in §[3]a few primitives inspired by Concurrent Constraint 
Programming (CCP 11221 ) to other primitives inspired by session types ifTTl . The key notions around 
which our primitives are conceived are principals and sessions. The former represent distributed units 
of computation that can advertise contracts, execute the corresponding operations, and establish/check 
agreements. Each agreement corresponds to a fresh session, containing rights and obligations of each 
stipulating party. Principals use sessions to coordinate with each other and fulfil their obligations. Also, 
sessions enable us to formulate a general notion of "misbehaviour" which paves the way for automatic 
verification. We finally suggest possible variants of our primitives and of the contract model (§ I3.6I ). 

Related Work. Multi-party session types |[T8l are integrated in (H with decidable fragments of first- 
order logic (e.g., Presburger arithmetic) to transfer the design-by-contract of object-oriented program- 
ming to the design of distributed interactions. We follow a methodologically opposite direction. In fact, 
in (21 one starts from a global assertion (i.e., global choreography and contracts) to arrive to a set of local 
assertions; distributed processes abiding with local assertions are guaranteed to have correct interactions 
(and monitors can be synthesized from local assertions to control execution in untrusted settings). In our 
framework instead, a principal declares its contract independently of the others and then advertises it; a 
CO2 primitive tries then to harmonise contracts by searching for a suitable agreements. In other words, 
one could think of our approach as based on orchestration rather than choreography. The same consid- 
erations above apply to [19 ] where protocol modelling (state machines with memory) represents global 
choreographies. There, contracts are represented as parallel state machines (according to a CSP-like 
semantics). Basically, the contract model of |fT9l coincides with its choreography model. 

In cc-pi flU, CCP is mixed with communication through name fusion. In this model, involved parties 
establish SLA by merging the constraints representing their requirements. Constraints are values in a 
c-semiring advertised in a global store. It is not permitted to merge constraints making the global store 
inconsistent, since an agreement cannot be reached in that case. Conversely, CO2 envisages contracts as 
binding promises rather than requirements. Actually, even if a principal A tells an absurdum, this will 
result in a contract like: "A is stating a contradiction" added to the environment. When this happens, 
our approach is not "contracts are inconsistent, do not open a session", but rather "A is promising the 
impossible, she will not be able to keep her promise, and she will be blamed for that". The cc-pi calculus 
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is further developed in Q to include long running transactions and compensations. There, besides the 
global constraint store, a local store for each transaction is featured. Local inconsistencies are then 
used to trigger compensations. In CO2 , compensations do not represent exceptional behaviour to be 
automatically triggered by inconsistencies; rather, compensations fall within "normal" behaviour and 
have to be spelt out inside contracts. Indeed, after a session has been established, each honest principal A 
either maintains her promises, or she is culpable of a violation; she cannot simply try to execute arbitrary 
compensations in place of the due actions. Of course, other principals may deem this promise too weak 
and avoid establishing a session with A. 

In lfT3l a calculus is proposed to model SLAs which combines 71-calculus communication, concurrent 
constraints, and sessions. There, the constraint store is global and sessions are established between two 
processes whenever the stated requirements are consistent. Interaction in sessions happens through com- 
munication and label branching/selection. A type system is provided to guarantee safe communication, 
although not ensuring progress. Essentially, the main role of constraints in this calculus is that of driving 
session establishment. Instead, in CO2 the contracts of an agreement leading to a session are still relevant 
e.g. to detect violations. 

A "boolean" notion of compliance between two contracts is introduced in lfl2l : either the contract 
of the client and one of the service are compliant, or they are not. In Ex. I3.4l we discuss a "multi-level" 
notion of compliance encompassing more than two contracts. Also, in |[T2l not compliant contracts, may 
become compliant by adjusting the order of asynchronous actions. When this is possible, an orchestrator 
can be synthesised from the client and service contracts. In some sense, the orchestrator acts as an 
"adapter" between the client and the service. In our approach, the orchestrator behaves as a "planner" 
which finds a suitable set of contracts and puts in a session all the principals involved in these contracts. 

CO2 takes inspiration from (3JI31. There, the contract language is the logic PCL, and contracts 
are recorded into a global constraint store. CO2 instead features local environments for principals and 
sessions to enable possible distributed implementations. 

Our approach differs from those discussed above, as well as from all the other approaches we are 
aware of (e.g. EKTOldll), w.r.t. two general principles. First, we depart from the common principle that 
contracts are always respected after their stipulation. We represent instead the more realistic situation 
where promises are not always maintained. As a consequence, in CO2 we do not discard contracts after 
they have been used to couple services and put them in a session, as done e.g. in all the approaches dealing 
with behavioural types. In our approach, contracts are also used to drive computations after sessions have 
been established (cf.§[3]>, e.g. to detect violations and to provide the agreed compensations. 

The second general difference is that CO2 smoothly allows for handling contracts-as-processes 
(cf.§ 12- lb - To the best of our knowledge, it seems hard to accomodate these contracts within frame- 
works based on constraint systems (lU[T3l), logics (GHH), or c-semirings (e.g. (H|7j[T5l). 

2 An abstract contract model 

We now sketch the basic ingredients of a generic contract model, before providing a formal definition. 

We start by introducing some preliminary notions and definitions; some of them will only be used 
later on in §[3] Principals are those agents which may advertise contracts, establish agreements, and re- 
alise them. Sessions are created upon reaching an agreement, and provide the context in which principals 
can interact to fulfil their contracts. Let 5\£ and V be countably infinite, disjoint sets of names and vari- 
ables, respectively. Assume j\£ partitioned into two infinite sets 0\[p and 9{$, for names of principals and 
of sessions, respectively. Similarly, V is partitioned into infinite sets %>p and I's for variable identifiers 
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n,m, . . . G 5\£ 


names, union of: 


A,B,... G Hp^l/p 


principal names/variables 


A, B, . . . e 5Vp 


principal names 


a,b, . . . EM 


atoms 


s,?,... G 5& 


session names 


(A i says ai, . . . ,Ay says ay) 


action 




variables, union of: 


c,c',... G C 


contracts 




principal variables 


C 


multisets of contracts 


x,y,... G 


session variables 


G * 


observables 


m,v,... g 5v; uv 


names or variables 


fi,f/,... 


labels 



Table 1: Notation 



of principals and sessions. A substitution is a partial map a from V to 2\£ ; we write u G doma when a is 
denned at u, and require that a maps a G doma n 'Up to ?V> and * G doma D ^5 to 
Our main notational conventions are displayed in Table [TJ 

The first ingredient of our contract model is a set C of contracts. We are quite liberal about it: we 
only require that A says c G C for all principals A and for all c G C. The contract A says c can be thought 
of as "c is advertised by A". A labelled transition relation A on contracts models their evolution under 
the actions performed by principals. 

Two further ingredients are a set <J> of observables (properties of contracts) and an entailment relation 
h between contracts and observables. Note that we keep distinct contracts from observables in our 
framework. This has the same motivations as the traditional distinction between behaviours (systems) 
and their properties (formulae predicating on behaviours), which brought in plenty of advantages in the 
design/implementation of systems. 

The last ingredient of our contract model is a relation © between contracts and principals. We write 
C©A to mean that, with respect to contracts C, all the obligations of the principal A have been fulfilled. 

Def . 12. 1 n ormalises the above concepts. 

Definition 2.1. A contract model is a tuple {c,& , — h, ©) where 

• C is a set of contracts, forming a subalgebra of a tenn-algebra 7V U5 ^ (E) for some signature £ 
which includes the operations u says _ for each u G V? U 9\(j> 

• A is a set of atoms ( ranged over by a, b, . . .) 

• C A C' is a labelled transition relation over finite multisets on C. The set of labels comprises 
actions, i.e. tuples of the form (Ai says ai , . . . , Aj says &j) 

• <J> is a set of observables, forming a subalgebra of a term-algebra T^ U9 ^ (L')for some signature £' 

• \- is a contract entailment relation between finite multisets of C and <£> 

• © is a contract fulfilment relation between finite multisets of C and principals. 

Example 2.1. We illustrate the contract model with the help of an informal example. A seller A and a 
buyer B stipulate a contract cq, which binds A to ship an item after B has paid. Let pay be the atom which 
models the action of paying. The transition cq Bsa - spa)/ - > Cj mo dels the evolution of Co into a contract c\ 
where A is obliged to ship, while B has no more duties. Now, let (j) be the observable "A must ship ". 
Then, we would have Co l/<t>, because A does not have to ship anything yet, while c\ h (|), because B has 
paid and so A must ship. It would not be the case that ci©A, because B has paid, while A has not yet 
fulfilled her obligation to ship. 
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jj ::= a I (A says a ) I (A says a ,A says a + ) 



Ei-a/.c, ^>c,- (Sum) 



Cl | C2 -> Cj | C 2 



(Par) 



x d = f c 



c — > c 



(Def) 



3 / / ^ 0\ 

c — >■ c /j = (A says a ) 
A says c — > A says c 



(Auto) 



ci c[ C2 — > c 2 /J = (Ai says a , A2 says a + ) 
Ai says ci | A2 says C2 A Ai says Cj | A2 says c 2 



(Com) 



Table 2: Labelled transition relation of contract-as-processes 



We remark that the use of term-algebras in Def. 12. H allows us to smoothly apply variable substitutions 
to contracts and observables. Accordingly, we assume denned the sets fv(c) and fv((j)) of (free) variables 
of contracts and observables. Note that actions are not required to be in C. Depending on the actual 
instantiation of the contract model, it can be useful to include them in C, so that contracts can record the 
history of the past actions. 



2.1 Contracts as processes 

The first instance of our contract model appeals to the contracts-as-processes paradigm. A contract is 
represented as a CCS-like process |[20l . the execution of which dictates obligations to principals. 

Definition 2.2. We define a contracts-as-processes language as follows 

• C is the set of process terms defined by the following grammar: 

c::= Li a i- c ( I A says c | c\c | X 

and £ is the signature corresponding to the syntax above; in this section, multisets of contracts are 
identified with their parallel composition, and accordingly we use the metavariable c to denote 
them. We assume variables X to be defined through (prefix-guarded recursive) equations. 

• A is the union of three disjoint sets: the "inputs" (ranged over by a~), the "outputs" (ranged over 
by a + ), and the "autonomous activities" (ranged over by a ). 

• A is the least relation closed under the rules in Table \2\ and structural equivalence = ( defined 
with the usual rules and A says = 0, where denotes the empty sum and trailing occurrences of 
may be omitted). 

• <I> is the set ofLTL M4\l formulae (on a signature YJ), where the constants are the atoms in 91. 

• c h (j) (for closed c and (|> ) holds when c \=ltl ^ according to the standard LTL semantics where, 
given a generic trace T| of c, the semantics of atoms is: 

r| |= a 3A,r\' . r\ = (A says a } a]' 

r\ \= a + <^=^ r| |= a~ <^=^ 3Ai,A 2 ,r|'. r) = (A\ says a~,A 2 says a + ) r\' 

• c©A holds iff for all c',c" such that c = (A says c') \ c" we have that c' = 0. 
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We briefly comment on the rules in Table |2 Intuitively, the relation A either carries labels of the 
form (A says a ), which instruct A to fulfil the obligation a , or labels (A\ says a~, Ai says a + ), which 
require participants A\ and A2 to fulfil the obligations a~ and a + , respectively. Rules (Sum), (Par), 
and (Def) are standard. By rule (Auto), a contract willing to perform an autonomous action a can do 
so and exhibit the label (A says a ). Rule (Com) is reminiscent of the synchronisation mechanism of 
CCS; when two complementary actions ST and a + can be fired in parallel, then the parallel composition 
of contracts emits the tuple (A\ says a~, A2 says a + ). Note that the rules in Table [2] give semantics to 
closed contracts, i.e. contracts with no occurrences of free variables. 

Example 2.2. Recall the buyer-seller scenario from Ex. \2.1\ The seller A promises to ship an item if 
buyer B promises to pay. The buyer B promises to pay. The contracts of IK and B are as follows: 

ca = A says pay ~. ship cb = B says pay + 

., . . (A savs pay" , B.vav.vpay + ) . n . (A says ship ) 
A possible computation is then: c& \ eg > A says snip | U > U. 



It is evident that the contract of B in Ex. 12.21 is rather naive; the buyer pays without requiring any 
guarantee to the seller (cf. Ex. 13.61 ). A possible solution is to use a (trusted) escrow service. 



Example 2.3. In the same scenario of Ex. \2.2\ consider an escrow service E which mediates between 
A and B. Basically, A and B trust the escrow service E, and they promise to ship to E and to pay E, 
respectively. The escrow service promises to ship to B and to pay A only after both the obligations of A 
and B have been fulfilled. The contracts of A, B, and E are defined as follows: 

c A = A.roysshipE+.pay - ce = E says shipE~. payE~. (pay+ | ship+) + 



— BrayspayE+.ship" payE . shipE . (pay+ | ship" 



2.2 Contracts as formulae 

For the second specialization of our generic model, we choose the contract logic PCL 0. A comprehen- 
sive presentation of PCL is beyond the scope of this paper, so we give here just a brief overview, and we 
refer the reader to (3JI3 for more details. 

PCL extends intuitionistic propositional logic IPC |[23l with the connective -», called contractual 
implication. Differently from IPC, a contract b -» a implies a not only when b is true, like IPC impli- 
cation, but also in the case that a "compatible" contract, e.g. a -» b, holds. So, PCL allows for a sort 
of "circular" assume-guarantee reasoning, summarized by the theorem h(b^>a) A (a^>b) — > a Ab. 
Also, PCL is equipped with an indexed lax modality _ says _, similarly to the one in lfl6l . 

The proof system of PCL extends that of IPC with the following axioms, while remaining decidable: 

T -» T $ — > (A says (j)) 

((()-»(())—)• (j) (A says A says — >■ A says (j) 

((j)' -> ((j) -» \|/) -> (\|/ -> \|/) -> ((j)' -» \|/) (<|> ->■ \|/) ->■ (A says (j)) -> (A says \|/) 

Following Def. 12.11 we now define a contract language which builds upon PCL . 



136 



Contracts in distributed systems 



Definition 2.3. We define a contracts-as-formulae language as follows: 

• C is the set of PCL formulae. Accordingly, £ comprises all the atoms A (see below), all the 
connectives of PCL, and the _ says _ modality. 

• A is partitioned in promises, written as a, and facts, written as !a. 

• The labelled relation A is defined by the rule: C - — — C, A says a, A says !a 

• <&=C, and £' = £. 

• h is the provability relation of PCL. 

• C©A holds iff C h A says a implies C h A says !a, for all promises a, each obligation for A 
entailed by C has been fulfilled. 

Note that the definition of A allows principals to perform any actions: the result is that C is aug- 
mented with the corresponding fact !a. We include the promise a as well, following the intuition that a 
fact may safely imply the corresponding promise. 

Example 2.4. The contracts of seller A and buyer Bfrom Ex. \2.1\ can be modelled as follows: 

ca = A says ((B says pay) — > ship) cq = B says pay 

By the proof system of PCL, we have that: ca A cq h (A .rays ship) A (B says pay). 

2.3 On contracts-as-processes vs. contracts-as-formulae 

We now compare contracts-as-processes with contracts-as formulae. We start with an empirical argu- 
ment, by comparing in Table [3] a set of archetypal agreements which use contracts from both paradigms. 
Our main technical result is Theorem 12.71 where we show that contracts-as-formulae, expressed in a 
significant fragment of PCL, can be encoded into contracts-as-processes. Finally, we further discuss the 
differences between the two contract models in some specific examples. 

Sketching a correspondence. We now discuss Table [3] Contracts yielding similar consequences lay 
on the same row. Each row tells when interaction is possible, i.e. when processes will eventually reach 0, 
and when the formulae entail the observable A says a A B says b. 

In row 1, B performs b unconditionally. Instead, A specifies in her contracts a causal dependency 
between b and a — using a prefix in the world of processes, or an implication in the world of formulae. 
Note that this exchange offers no protection for B, i.e., ca could be replaced with anything else and B 
would still be required to provide b. 

In row 2, B protects himself by using a causal dependency, using the dual contract of ca- Now 
however interaction/entailment is lost: every principal requires the other one to "make the first step", and 
circular dependencies forbid any agreement. 

In row 3, B makes the first step by inverting the order of the causal dependency in cb- The outcome 
is similar to row 1, except that now the contract of B mentions that B expects a to be performed. The 
meaning of the process is roughly "offer b first, then require a" which has no analogous contract-as- 
formula. 

In row 4, B is offering b asynchronously, so removing the causal dependency. In the world of 
processes, this is done using parallel composition instead of a prefix; in the world of (PCL) formulae this 
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A says b~.a u 


A says (B says b) — > a 


1. 


CB 


B says b + 


B says b 






no protection, interaction 


no protection, entailment 




CA 


A says b~.a + 


A says (B says b) — > a 


2. 


CB 


B says a~.b + 


B says (A says a) — > b 






no interaction 


no entailment 




CA 


A says b~.a + 




3. 


CB 


B says b + .a~ 


(no equivalent) 






asymmetric, interaction 






CA 


A says b~.a + 


A says (B says b) — ► a 


4. 


CB 


B says b + a~ 


B says (A says a) ^> b 






asymmetric, interaction 


asymmetric, entailment 




CA 


A says b~ a + 


A says (B says b) -» a 


5. 


CB 


B says b + a~ 


B says (A says a) -» b 






symmetric, interaction 


symmetric, entailment 



Table 3: Contracts-as-processes vs. contracts-as-formulae 



is done using -» instead of — K Interaction/entailment is still possible. The contracts ca and cb are not 
symmetric, in which case ca specifies a causal dependency, while cb does not. 

In row 5, causal dependency is removed from ca as well. Both A and B are using parallel composi- 
tion/contractual implication. This results in symmetric contracts which yield interaction/entailment. 

A formal correspondence between contract models. We now provide a precise correspondence be- 
tween two fragments of contracts-as-formulae and contracts-as-processes, building upon the intuition 
underlying the cases shown in Table [3] 

Concretely, we consider a fragment (PCL~) of PCL contracts comprising atoms, conjunctions, says, 
and non-nested (contractual) implications. Then, we provide an encoding of PCL into contract-as- 
processes (Def . 12.51 ) and formally relate them. 

Definition 2.4. We define PCL as the fragment of PCL where formulae c have the following syntax: 
c ::= f\ iei A t says (Xi 



a ::= A 



(Aie/ B > ™ys p,-) -> f\ je} q y - (/\ iei B t says p ; ) -» /\ jej q 7 - 



Definition 2.5. For all formulae c of PCL - , we define the contract-as-process [c] as follows, where, for 
all atoms q, OUT(q) is a recursive process defined by the equation OUT(q) = T°.O + q + .0LT(q). Also, 
we assume an injective function _/ that maps all atoms q and all principals A into the atom q/ A . 

[f\ ieI At says a,-] = | \ iei A, says [a ; -] A ,- 

[/WqjU = Wjej OUT(q j/A ) 

[(Aie{l,...,»} Bi says p ; ) ->• f\ jey q y -] A = p^ fll . • ■ • .p~ /Bfl . (| |y ej OUT(q j/A )^ 

[(A/e{i,..., n } BiSaysPi)^ Aje^jU = [Wjej OUT(q J/A )) p^. • • • -P~ /Bn -0 

In Def. 12. 61 below we extract from a PCL contract c the associated ZateTi? actions, i.e. the set of all 
atoms occurring in c paired with the participant who may have to abide by. 
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Definition 2.6. The function Xfrom PCL formulae to sets of actions is defined as follows: 

HAiei A i sa y s a = Uiei ^Ai(cCi) 
^(A/ejr q 7 ) = {A «fyj q 7 - | j G j/} 

M(Ate? s < P;) -» Aje? q y -) = {A rays q y - | j G J/ } U {£,• says p f | / G / } 
M(A*e/ 5; rays p,-) -» Ajej; q y = says q y - | ;' G 3 } U {£«■ rays p,- | i G / } 

The following result establishes a correspondence between our contract models. A PCL contract c 
requires to perform all the latent actions iff its encoding [c] can be fulfilled. 

Theorem 2.7. For all PCL formulae c involving principals {A,-}, e /, the following are equivalent: 

• (contracts-as-formulae) Vc . . . ,/!„. 

(( c . . . ^ d A Vi G /. c'©A,-) C { W , . . . >/ifl }) 

• (contracts-as-processes) 3c' . ([c] — >* c' A V/ G /. c'OAj) 

The above statement can in fact be reduced to the result below by considering the definition of © in 
both contract models. 

Theorem 2.8. For all PCL~ formulae c, c h X,(c) //'anJ orc/y [c] — >* 0. 

The "if" direction mainly follows from the fact that, unless a x° is fired, the residuals of [c] are of the 
form [c'\ where d is a formula equivalent to c. The "only if" direction is proved by considering the order 
of applications of modus ponens in a proof of c h X(c) and consequently firing the inputs corresponding 
to premises of implications. This makes their consequences/outputs available. The case of contractual 
implications is simpler because outputs are immediately available, hence their generated inputs can be 
fired last. 

3 A basic calculus for contract-oriented computing 

We now introduce the syntax and semantics of CO2. It generalises the contract calculus in Q by making 
it independent of the actual contract language. In fact, CO2 assumes the abstract model of contracts intro- 
duced in §|2 which can be instantiated to a variety of actual contract languages. While taking inspiration 
from Concurrent Constraint Programming, CO2 makes use of more concrete communication primitives 
which do not assume a global constraint store, so reducing the gap towards a possible distributed im- 
plementation. The main differences between CO2 and CCP are: (i) in CO2 constraints are multisets of 
contracts, (h) in CO2 there is no global store of constraints: all the prefixes act on sessions, (Hi) the pre- 
fix ask of CO2 also instantiates variables to names, and (iv) the prefixes do (which makes a multiset of 
constraints evolve) and fuse (which establishes a new session) have no counterpart in CCP. 

3.1 Syntax 

First, let us define the syntax of CO2. 

Definition 3.1. The abstract syntax of CO2 is given by the following productions: 



Systems 


S ::= 


A[P] 


s[C] 


S | 5 


(u)S 


Processes 


P ::= i u c 




P\P 


(u)P 


X(u) 


Prefixes 


71 ::= x 


do,, a 


te\\ u l v c 


ask Bi ?<t> 


fuse,, (j) 



We stipulate that the following conditions always hold: in a system | |, e/ ?i,[P,'], n, 7^ njfor each i 7^ j G I; 
in a process (u)P and a system (u)S, u 9{p. 
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commutative monoidal laws for | on processes and systems 
u[(v)P] = (v)u[P) ift/^v Z\{u)Z' = {u){Z\Z') if u £fv(Z) Ufn(Z) 



(k)(v)Z=(v)( M )Z 



(u)Z = Z if M0fv(Z)Ufn(Z) 



= 



tell,, |„c.P 



= 



ask„, P (|).P = if v 5^0 



fuse„(j).P = 



Table 4: Structural equivalence (Z,Z' range over systems or processes) 



We distinguish between processes and systems. Systems S consist of a set of agents A[P] and of 
sessions s[C], composed in parallel. Processes P comprise latent contracts, guarded summation, parallel 
composition, scope delimitation, and process identifiers. A latent contract ], x c represents a contract 
c which has not been stipulated yet; upon stipulation, the variable x will be bound to a fresh session 
name. We allow finite prefix-guarded sums of processes; as usual, we write 7ii .Pi + 712.P2 for Ei=i 2 71; .P;. 
Processes can be composed in parallel, and can be put under the scope of binders We use process 
identifiers X to express recursive processes, and we assume that each identifier has a corresponding 
defining equation X(u\,..., uj) = P such that fv(P) C {ui,. .. , uj} C 1/ and each occurrence of process 
identifiers Y in P is prefix-guarded. Note that principal names cannot be bound, but can be communicated 
if permitted by the contract language. The empty system and the empty sum are both denoted by 0. As 
usual, we may omit trailing occurrences of in processes. Free/bound occurrences of variables/names 
are defined as expected. Variables and session names can be bound; in (u)S all free occurrences of u in S 
are bound; S is closed when it has no free variables. Prefixes include the silent prefix X, action execution 
do„a, contract advertisement tell H J, v c, contract query ask u ?§, and contract stipulation fuse„(j). The 
index u indicates the target agent/session where the prefix will be fired or the session where stipulations 
are kept, in the case of fuse. We shall refer to the set of latent contracts within an agent A[P] as its 
environment; similarly, in a session s[C] we shall refer to C as the environment of s. Note that the 
environment of agents can only contain latent contracts, advertised through the primitive tell, while 
sessions can only contain contracts, obtained either upon reaching an agreement with fuse, or possibly 
upon principals performing some do prefixes. 

3.2 Semantics 

The semantics of CO2 is formalised by a reduction relation on systems which relies on the structural 
congruence laws in Table @] Only the last row in Table @] contains non-standard laws: they allow for 
collecting garbage terms which may possibly arise after variable substitutions. 

Definition 3.2. The binary relation — > on closed systems is the smallest relation closed under structural 
congruence and under the rules in Table\5\ where the relation K D>° (j) in (FUSE) is introduced in Def. \3.3\ 
and IK is obtained by removing all the \._ from K, i.e. if K = || ie / \. Xi c,-, then ^ K = ||, e /c,-. Also, we 
identify the parallel composition of contracts C = c\ \ . . . \ Cj with the multiset {ci, . . . ,c/} (similarly for 
latent contracts). 

Axiom (Tau) and rules (Par), (Del), and (Def) are standard. Axioms (TelLi) and (Tell 2 ) state 
that a principal A can advertise a latent contract ], x c either in her own environment, or in a remote one. In 
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A[x.P + P' \Q]^A[P\Q] 


(Tau) 


AftelU Lc P + P' 1 O] — > Af L A savs c 1 P 1 01 


fTELLi ) 


A[tell B 4 cP + P 7 | 2] 1 B[R]-)-A[P|e] | B[fl |4 A-royj c] 


(Tell 2 ) 


(Ai saysai,. .., Ajsays a y -> , 
C S»C 7>1 


(DO) 


*[C] | ||i<KyA ; -[do. v a,-.P ; - + P;|a-]->4C] I ||i<i<iA,[Pj|a-] 


domo = «Ci/ Cah(|)a 
(w)(A[ask,, i? (t).P + P' | 2] | s[C] | 5) -»• A[P | Q]a \ s[C]a \ So 


(Ask) 


K >° § « = domaC V 5 = a(x) fresh 


(Fuse) 


(i7)(A[fuse. Y fP + P' \K\Q]\S)^ (s)(A[P \ Q]a \ s[t K]o \ Sc) 


X(u)^P P{Vu}^P' 
X(v)^P' 


(Def) 


S 1 5" -> 5' | 5" 


(Par) 


S->S' 
(u)S -> (m)S' 


(Del) 



Table 5: Reduction semantics of CO2 
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(Do), the principals A,- are participating in the contracts C stipulated on session s. Basically, the system 
evolves when all the involved principals are ready to fire the required action. Rule (Ask) allows A to 
check if an observable (]) is entailed by the contracts C in session s; notice that the entailment is subject 
to an instantiation a of the variables mentioned in the ask prefix. Rule (Fuse) establishes a multi-party 
session s among all the parties that reach an agreement on the latent contracts K. Roughly, the agreement 
relation K \>°. (j) (Def. 13.31 ) holds when, upon some substitution a, the latent contracts K entail ()), and the 
fresh session name s substitutes for the variable x. 

The simplest typical usage of these primitives is as follows. First, a group of principals exchanges 
latent contracts using tell , hence sharing their intentions. Then, one of them opens a new session using 
the fuse primitive. Once this happens, each involved principal A can inspect the session using ask , hence 
discovering her actual duties within that session: in general, these depend not only on the contract of A, 
but also on those of the other principals (see e.g. Ex l3.4l) . Finally, primitive do is used to actually perform 
the duties. 

Example 3.1. The sale scenario between seller A and buyer Bfrom Ex. \2.4\ can be formalized as follows. 

S = A[(x,b) tellA^.v {{b says pay) — > ship). fuse,, (A says ship). do, ship] 
| B[(y) tell A 4v pay- 3sk y (B says pay). do,, pay] 

The buyer tells A a contract which binds B to pay, then waits until discovering that he actually has to pay, 
and eventually does that. A session between the buyer and the seller is created and proceeds smoothly 
as expected: 

S — > (x,b,y) (A [4* A says ({b says pay) — > ship) | fuse r (A says ship). do x ship] 
| B[tell A 4,, pay. ask,, (B says pay), do,, pay] ) 

— > (x,b,y) {A[\y B says pay | i x A says ((b says pay) — > ship) | fuse,, (A says ship). do. Y ship] 
| B[ask,. (B says pay), do,. pay] ) 

— > (s) (A[do 5 ship] | B[ask v (B says pay). do. s pay] | s[A says ((B says pay) ship) , B says pay]) 

— > (s) (A[do 4 ship] | B[dospay] | s[A says ((B says pay) — > ship) , B says pay] ) 

— > (s) (A[0] | B[do. v pay] | s[A says ((B says pay) — > ship) , B says pay , A says !ship , . . .] ) 

— > (s) (A[0] I B[0] | s[A says ((B says pay) — > ship) , B says pay , A says !ship , B says !pay , . . .' 

In the previous example, we have modelled the system outlined in Ex. 12.11 using a contracts-as- 
formulae approach. In the following example, we adopt instead the contracts-as-processes paradigms. In 
the meanwhile, we introduce a further participant to our system: a broker C which collects the contracts 
from A and B, and then uses a fuse to find when an agreement is possible. 
Example 3.2. Recall the contract of Ex. \2.2\ We specify the behaviour of the system as: 

S = A[(x)(tellc (|.v pay~.ship°). ask v Opay + . do Y pay~. do x ship°] 
B[(j)(tellc|„pay + .do v pay+] 
| C[(z)(fuse. 0(pay+ AOship ))] 

The principals A and B advertise their contracts to the broker C, which opens a session for their inter- 
action. As expected, as soon as the payment is received, the goods are shipped. After advertising such 
contract in her environment, the seller waits until finding that she has promised to ship; after that, she 
actually ships the item. 

S ^* (s) (A[0] | B[0] | .[0]) 
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3.3 On agreements 

To find agreements (K D>J (j)), we use the relation h of the contract model. 

Definition 3.3. For all multisets K of latent contracts, for all substitutions o : V — >■ $t , for all x £ V ' ,for 
all observables (j), we write K \>° (]) iff the following conditions hold: 

• x € doma 

• fv(Ko) = fv((|>c) = 

• 3s G 9{s ■ Yy G doma n V s : a(y) = s 

• (t^)ah(^a 

• no o' CO satisfies the conditions above, i.e. a is minimal. 

Basically, Def. [33] states that an agreement is reached when the latent contracts in K entail, under a 
suitable substitution, an observable (]). Recall that (j) is the condition used by the principal acting as broker 
when searching for an agreement (cf. rule (Fuse) in Table [5]). A valid agreement has to instantiate with 
a minimal substitution a all the variables appearing in the latent contracts in K as well as the session 
variable x; the latter, together with any other session variables in the domain of the substitution a, is 
mapped to a (fresh) session name s. 

The minimality condition on o forces brokers to include in agreements only "relevant" participants. 
For instance, let \. Xl c\, \. X2 C2, and 4* 3 C3 be the latent contracts advertised to a broker; if there is an 
agreement on | Vl c\ and \, X2 C2, the latent contract | V3 C3 would not be included. Basically, the minimality 
condition allows brokers to tell apart unrelated contracts. This is illustrated by the following informal 
example. 

Example 3.3. Let (j) be the observable "A shall ship the goods ", and consider the following latent 
contracts, advertised by A, B, and C, respectively: 

• ixi c\ = "in session x\, if some principal b pays, then I shall ship the goods" 

• i* 2 c 2 = "in session xj, I shall pay " 

• i* 3 C3 = "in session xt,, I shall kiss a frog". 

Note that the first two latent contracts do entail (}> when o(b) = B, and o(xi) = 0(^2) = s - Without the 
minimality condition, (5{xj) = s would have been included in the agreement of A and B, despite the offer 
of C being somewhat immaterial. 

Example 3.4. Our approach allows for contract models with multiple levels of compliance. For instance, 
let ca, cb, and cqi be the following PCL contracts: 

ca =ixi A says ((b says b) — > a A (b says b') — > a') c& =\. X2 B says b cb' =4. Y3 B' says b A b' 

The contract ca is intuitively compliant with both cb and cqi. When coupled with cqi, the contract ca 
entails both the obligations a and a' for A. Conversely, when coupled with cq, we obtain a weaker 
agreement, since only the obligation a is entailed. Although both levels of agreement are possible, in 
some sense the contract cb' provides ca with a better Service-Level Agreement than cq. Through the 
primitive ask, principal A can detect the actual service level she has to provide. 
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3.4 On violations 

In Def. |3.4| below we set out when a principal A is honest in a given system 5. Intuitively, we consider 
all the possible runs of S, and require that in every session the principal A eventually fulfils all her duties. 
To this aim, we shall exploit the fulfilment relation C©A from the contract model. 

To do that, we need to cope with a few technical issues. First, the a-conversion of session names 
makes it hard to track the same session at different points in a trace. So, we consider traces "without 
a-conversion of names". Technically, let 



and define 5 ~^ 5" whenever S — s> S' and S" G freezeNames(S') . A —>-trace is a trace w.r.t. Such a 
-^-trace is maximal iff it is either infinite or ending with Sj 

Another technical issue is that a principal could not get a chance to act in all the traces. For instance, 

consider the system S = A[do v pay] | B[X] | S' where S' enables A's action and X = f x.X; note that S 
generates the infinite trace S ~» S ~» S ~» • • • in which A never pays, despite her honest intention. To 
account for this fact, we will check the honesty of a principal in fair traces, only, i.e. those obtained by 
running 5 according to a fair scheduling algorithm. More precisely, we say that -^-trace (£;),• is fair if 
no single prefix can be fired in an infinite number of 5,. 

Definition 3.4. A principal A is honest in S iff for all maximal fair -^-traces (S,), e /, 



In other words, a principal A misbehaves if involved in a session s such that the contracts C of s do 
not settle the obligations of A. 

Example 3.5. Consider the variation ofEx. UJ] where the seller is modified as follows: 

S = A[(x,b) telULv {{b says pay) — > ship). fuse x (A says ship). do T snakeOil] 
| B[(y) telUlv pay- ask v (B says pay). do_ v pay] 

The fraudulent seller A promises to ship — but eventually only provides the buyer with some snake oil. 
The interaction between A and B leads to a violation: 



The buyer has not obtained what he has paid for. Indeed, the seller is dishonest according to Def. \3.4\ 
because the contracts in s entail the promise A says ship, which is not fulfilled by any fact. A judge may 
thus eventually punish Afar her misconduct. 

3.5 On protection 

We now illustrate some examples where one of the parties is fraudulent. 

Example 3.6. Recall Ex. \3.5\ and consider a fraudulent seller A, which promises in her contract some 
snake oil. The buyer B is unchanged from that example. 

S = A[(x,b) telUlx ((b says pay) — > snakeOil). fuse* (A says snakeOil). do. v snakeOil] |B[. ..] 



freezeNames(S) = {S 1 \ S = (si, . . .,sj)S r and S' free from (s) delimitations} 




S ^* (s) (A[0] | B[0] | s[Asays ((B says pay) ^ ship), A says IsnakeOil 

B says pay, B says !pay, . . .]) 
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The interaction between A and B now goes unhappily for B: he will pay for some snake oil, and A is not 
even classified as dishonest according to Def. \3.4\ indeed, A has eventually fulfilled all her promises. 

S — >* (s) (A[0] | B[0] | s[Asays IsnakeOil, B says !pay, ...]) 

Example 3.7. To protect the buyer from the fraud outlined in Ex. \3.6\ we change the contract of the buyer 
B as follows: 

S = &[(x,b) telUlj ((b says pay) — >snakeOil). fuse r (Asa;yssnakeOil). do v snakeOil] 

B[(a,y) tellA^v i a says ship) -» pay. ask v (B says pay), do,, pay] 

Note that we have used contractual implication -», rather than standard implication — >, which allows B 
to reach an agreement also with the honest seller contract (b says pay) — > ship. Instead, the interaction 
between the above fraudulent seller A and the buyer B will now get stuck on the fuse in A, because the 
available latent contracts do not entail A says snakeOil. 

When using contracts-as-processes, a broker can participate in deceiving a principal. 
Example 3.8. Consider a simple e-commerce scenario: 

S = Ai[(x)tellB^.r (pay + .ship~). do^pay + . do v ship~] 

I A 2 [(y)tell B .j.y (pay~.(ship+ + fraud )). do y pay~. do y fraud°] 
| B[(z)fuse. 0(ship+V fraud )] 

Above, the broker B and A 2 dishonestly cooperate and open a session to swindle A] . The principal A2 
will be able to fulfil her contract (C©A2), while Ai will never receive her goods. Nevertheless, Ai is 
considered culpable, because he cannot perform the promised action ship . In Sect. 13.61 we propose a 
variant of the contracts-as-processes model allowing principals to protect from such kind of misbehavior. 
Example 3.9. Consider the following formalization of the e-commerce scenario: 

S = Ai[(;c,a2)tellB^U («2 says ship -» pay). ask v Ai says pay. do r pay] 
A 2 [(j,ai)tellBlv ( a i sa y s P a y ~» (ship V fraud)). do v fraud] 
I B[(z)fuse^] 

Here, choose (]) so to cause Ai and A 2 to initiate a session (the actual formula is immaterial). 

In Ex. 13.91 even if a session is established by the dishonest broker, Ai will not pay, and he will not 
be considered culpable for that. Indeed, the prefix ask Y Ai says pay is stuck because the contracts in the 
session do not entail any obligation for Ai to pay. For the same reason, Ai will fulfil her contract (COAi). 

In the following example, we show a different flavour of "protection": the principals A and B are not 
protected by their contracts, but by the trusted escrow service that acts as a broker. 
Example 3.10. Recall the scenario in Ex \2. 3\ The system is modelled as follows: 

S = A[(Y)(tellE4;t (shipE + .pay~). do. v shipE + . ask r <C>pay + . do v pay~)] 
B[(j)(tellE4y (payE + .ship~). do v payE + . ask v Oship + . do. t ship - )] 
E[(z)(tell E | z c E . fuse,f.P)] 
ce = shipE~. payE~. (pay + | ship + ) + payE~. shipE~. (pay + | ship + ) 

where P is the obvious realization of the ce, and (])' = 0(shipE + A Opay + ) A 0(payE + A Oship + ). 

The escrow service guarantees each of the participants A and B that the other party has to fulfil its 
obligation for the contract to be completed. The systems S can perform the wanted interaction: 

(,)(A[0]|B[0]|E[0]|,[0]) 
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3.6 Variants to the basic calculus 

Several variants and extensions are germane to CO2. We mention a few below. 

Protection for contracts-as-processes. The contracts-as-processes model can be adapted so that 
CO2 processes can protect themselves from untrusted brokers. In this variant, contractual obligations 
would derive only from mutually compliant contracts, i.e. c h $ should hold only when all the (fair) traces 
of c lead to 0, in addition to c \=ltl §■ Similarly, c©A should also hold on non-mutually-compliant c, 
since in this case no obligation arises. With this change, even if a principal A is somehow put in a session 
with fraudulent parties, A can discover (via ask) that no actual obligation is present and avoid being 
swindled. 

Contracts-as-processes with explicit sender and receiver. The syntax of contracts-as-processes 
(Def. 12.21 ) can be extended so to make explicit the intended senders/recipients of inputs/outputs (per- 
mitting e.g. to clearly state who is paying whom). For this, we could use e.g. pay + @B as atoms, and 
adapt the semantics A accordingly. 

Note that the logic for observables <J> in Def. l2.2l should be adapted as well. Indeed, LTL does not dis- 
tinguish between actions performed by distinct principals. To this puipose, we would allow A says a + @ B 
(and related a~ , a variants) as prime formulae, so that it is now possible to observe who are the principals 
involved by an action. 

Note that the changes discussed above do not alter the general calculus CO2, but merely propose a 
different contract model. 

Local actions. In CO2, agents A[P] only carry latent contracts in P. Hence, communication between 
principals is limited to latent contract exchange. Allowing general data exchange in CO2 can be done in 
a natural way by following CCP. Basically, P would include CCP contraints t, ranging over a constraint 
system (T,\~), a further parameter to CO2. Assume that A says t G T for all t G T and for all A. The 
following rules will augment the semantics of CO2 (the syntax is extended accordingly): 

A[tell A f.P + P' I Q] — > A [A says t \ P \ Q] 

A[te\\ B t.P + P' I Q] I B[R] ^A[P \ Q] | B[A says t \ R] 

A[ask A f .P + P' \T\Q] A[P\T\Q) provided that T h t 

Note that the above semantics does not allow A to corrupt the constraint store of B augmenting it with 
arbitrary constraints. Indeed, exchanged data is automatically tagged on reception with the name of the 
sender. So, in the worst case, a malicious A can only insert garbage A says t into the constraint store of B. 

Retracting latent contracts. A retract primitive could allow a principal A to remove a latent contract 
of hers after its advertisement. Therefore, A could change her mind until her latent contract is actually 
used to establish a session, where A is bound to her duties. 

Consistency check. The usual check t primitive from CCP, which checks the consistency of the con- 
straint store with t, can also be added to CO2. When check t is executed by a principal A[P], t is checked 
for consistency against the constraints in P. Note that checking the whole world would be unfeasible in 
a distributed system. 
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Forwarding latent contracts. A forward primitive could allow a broker A to move a latent contract 
from her environment to that of another broker B, without tagging it with A says . In this way A delegates 
to B the actual opening of a session. 

Remote queries. More primitives to access the remote principals could be added. Note however that 
while it would be easy e.g. to allow Afaske?] to query the constraint of B, this would probably be 
undesirable for security reasons. Ideally, B should be allowed to express whether A can access his own 
constraint store. This requires some access control mechanism. 

4 Conclusions 

We have developed a formal model for reasoning about contract-oriented distributed programs. The 
overall contribution of this paper is a contract calculus (CO2 ) that is parametric in the choice of contract 
model. In CO2, principals can advertise their own contracts, find other principals with compatible con- 
tracts, and establish a new multi-party session with those which comply with the global contract. We have 
set out two crucial issues: how to reach agreements, and how to detect violations. We have presented 
two concretisations of the abstract contract model. The first is an instance of the contracts-as-processes 
paradigm, while the second is an instance of the contracts-as-processes paradigm. 

As a first step towards relating contract-as-processes and contracts-as-formulae, we have devised a 
mapping from contracts based on the logic PCL Q into CCS-like contracts. One can then use contract- 
as-formulae at design-time, reason about them using the entailment relation of PCL, and then concretise 
them to contracts-as-processes through the given mapping. Theorem 12.71 guarantees that contracts-as- 
processes can reach success in those cases in which an agreement would be possible in the logic model, 
hence providing a connection between the two worlds. 
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